An ongoing trend within telecommunications is the convergence of fixed and mobile networks, which is known as Fixed Mobile Convergence (FMC). The trend of evolving networks using IP-based technologies is common for fixed and mobile networks, which makes the convergence easier. By FMC, mobile and fixed network operators will be able to utilize their network resource more efficiently, which leads to reduction of capital and operational expenditure (CAPEX and OPEX). For instance, when a user is running an IP-based application such as Multimedia Telephony (MMTel) inside their home, it is more efficient to utilize broadband connectivity of the fixed access network rather than the wireless access network.
Residential networks have been important to the success of FMC because they are the most commonly used fixed network access by ordinary users. Therefore, it is important to be able to connect mobile phones to the Evolved Packet Core (EPC; see “Architecture enhancements for non-3GPP Accesses,” 3GPP TS 23.402, V10.3.0, 2011-03; http://www.3gpp.org/ftp/specs/html-info/23402.htm) through a residential network. The term User Equipment (UE) can be used in place of the term mobile terminal or mobile phone. The term UE is familiar in the 3rd Generation Partnership Project (3GPP) documentation, and is intended to refer to any piece of equipment that is configured to access the internet; it would include, for example and without limitation, mobile telecommunication devices, portable or handheld computing devices and desktop or installed computers.
3GPP (3rd Generation Partnership Project) defines mobile 2G/3G/LTE accesses and “non-3GPP accesses” (TS 23.402). The latter can be a fixed network. Many UEs address the FMC trend by providing multiple radio interfaces: one interface to connect to a 2G/3G/LTE access and a WiFi interface to connect to a fixed network. The BBF (BroadBand Forum, the standardization organization for the fixed access; see http://www.broadband-forum.org/) defines an architecture for fixed networks. There is an ongoing joint work item on FMC between these two organizations [3GPP TR 23.839, now moving into TS 23.139, and BBF WT 203].
There are a number of ongoing work items on Fixed Mobile Convergence (FMC). In FMC, a dual-radio UE is generally assumed. The UE has one radio interface for the 3GPP access (e.g. LTE), and one radio interface for the fixed access (e.g. WiFi). In 3GPP, “Study on Support of BBF Access Interworking” (BBAI) covers interworking between 3GPP (the standardization organization for mobile networks) and BBF (the standardization organization for fixed networks) [3GPP TR 23.839, TS 23.139, BBF WT 203]. Another work item in 3GPP, “Study on S2a Mobility based On GTP & WLAN access to EPC” (SaMOG) covers the standardization of a 3GPP network interworking with a WiFi radio access [3GPP TS 23.852]. Additional standardization activities are ongoing in the WiFi Alliance.
In the WiFi Alliance, one of the focus areas is (public) hotspots. Therefore, in addition to the residential networks described above, hotspots are increasingly becoming key to the success of FMC, and there is a work item in 3GPP called SaMOG (Study on S2a mobility based on GTP & WLAN access to EPC; see 3GPP TR 23.852 at http://www.3gpp.org/ftp/Specs/html-info/23852.htm). SaMOG is specific to S2a, but not specific to BBF.
A 3GPP UE can attach to a non-3GPP access network (e.g. a fixed network) and connect to one or more Packet Data Networks (PDNs) via the S2 interface [3GPP TS 23.402]. The S2 interface comes in three types: S2a, S2b and S2c. In S2a, the non-3GPP access network is seen as trusted; the non-3GPP access network is therefore denoted as TNAN (Trusted Non-3GPP Access Network). Where the TNAN uses Wireless LAN (WLAN) as the radio technology towards the UEs, the TNAN is denoted as TWAN (Trusted WLAN Access Network). A TWAN would typically comprise a Residential Gateway (RG), an Access Node and a gateway node denoted as a TWAN Access Gateway (TWAG).
FIG. 1 of the accompanying drawings is a schematic illustration of a roaming scenario, in which a UE 2 connects to its Home PLMN (HPLMN) 8 via an Access Network (AN) 4-1 and a Visited PLMN (VPLMN) 6-2, where PLMN stands for Public Land Mobile Network. As illustrated in FIG. 1, a HPLMN might have roaming agreements with several VPLMNs, and a VPLMN can have operating agreements with several AN domains, and vice versa. For example, in FIG. 1, the HPLMN 8 has a roaming agreement with VPLMN 6-2 and VPLMN 6-3; VPLMN 6-1 and VPLMN 6-2 each have an operating agreement with AN 4-1 and AN 4-2, while VPLMN 6-3 has an operating agreement with AN 4-2. In some scenarios, the AN and VPLMN are, or can be considered to be, the same. One example where the VPLMN and AN can be different domains is the above-mentioned FMC (reference architectures for FMC scenarios are listed in TR 23.839, which can be found at http://www.3gpp.org/ftp/specs/html-info/23839.htm). In such a scenario, an example of the AN is the above-mentioned BBF domain.
One technical challenge which has previously been identified in this context is that of finding an appropriate ePDG (evolved Packet Data Gateway) for the UE where the UE is able to roam, such that the UE may connect to its HPLMN directly or via an intermediate VPLMN depending on where the UE is located.
TS 23.402 explains (see section 4.3.4) the functionality of an ePDG (evolved Packet Data Gateway); the main function of the ePDG is to secure the data transmission with a UE connected to the EPC over an untrusted non-3GPP access, acting as a termination node of IPsec tunnels established with the UE.
TS 23.402 also defines (see section 4.5.4) how a UE finds the ePDG (evolved Packet Data Gateway). In a roaming scenario, the UE constructs an FQDN (Fully Qualified Domain Name) using the VPLMN ID.
In this respect, creation of the FQDN is as set out in TS 23.003 (http://www.3gpp.org/ftp/specs/html-info/23003.htm). The FQDN is of the format “epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org”, where the Mobile Country Code (MCC) and the Mobile Network Code (MNC) are obtained or derived from the PLMN ID. For example, where the PLMN ID indicates that MCC=234 and MNC=15, then the FQDN would be constructed as epdg.epc.mnc015.mcc234.pub.3gppnetwork.org.
Following construction of the FQDN, the UE selects an ePDG IP address (IP@) from the list returned in the Domain Name System (DNS) response and initiates the IPsec tunnel establishment. If the VPLMN ID is unknown, the UE constructs an FQDN using the HPLMN ID.
More specifically, TS 23.402 explains that the UE may select the ePDG by static configuration or dynamically. If a selected ePDG is not reachable from an untrusted non-3GPP access the UE repeats the ePDG selection and selects a different ePDG if available.
TS 23.402 goes on to explain that, if the ePDG needs to be dynamically selected when the UE roams in a VPLMN whose VPLMN ID is known by the UE, the procedure is as follows:                The UE constructs an FQDN using the VPLMN ID as the Operator Identifier and employs the DNS server function to obtain the IP address(es) of the ePDG(s) in the VPLMN.        The UE selects an ePDG address from the list returned in the DNS response and initiates the IPsec tunnel establishment.        
Otherwise, as TS 23.402 explains, if the ePDG needs to be dynamically selected the procedure is as follows:                The UE constructs an FQDN using the HPLMN ID and employs the DNS server function to obtain the IP address(es) of the ePDG(s).        The UE selects an ePDG address from the list returned in the DNS response and initiates the IPsec tunnel establishment.        
The present applicant has appreciated the following issues with the presently defined techniques.
In certain roaming scenarios (for example, an FMC scenario as referred to above), the UE has no standardized means to discover the VPLMN ID. Therefore, there will be cases where only the HPLMN ID is known to the user.
3GPP contribution TS S2-103510 (available at http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_80_Brunstad/Docs/S2-103510.zip) proposes to allow the UE to contact the H-ePDG (Home ePDG) directly, also in roaming scenarios. This is an addition to the existing FMC reference architectures in TS 23.839.
For roaming scenarios TS S2-103510 proposes: “If the UE selects the ePDG that belongs to HPLMN the traffic is routed to the HPLMN via the SWu/SWn interface. According to the IP routing implemented the SWu/SWn may not traverse the VPLMN. The S9* session may be established via V-PCRF or directly between the H-PCRF and the BPCF, if allowed by agreement between the parties and the network configuration”.
The solution proposed in TS S2-103510 allows the traffic to bypass the VPLMN completely—the Internet becomes the transport network between the BBF domain and the HPLMN. The roaming scenario basically becomes a non-roaming scenario. In some cases, this might be what the operator wants. However, it is desirable that a solution is also available where the traffic really is routed via a VPLMN.
Another previously-considered solution is based on DNS: the UE can construct the FQDN with its location, e.g. the Routing Area Identity/Tracking Area Identity (RAI/TAI) in 3GPP Access. The result of the ePDG FQDN would be: “UE-location.epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org”.
However, the RAI/TAI might not be available to the UE, for example if there is no 3GPP RAN (Radio Access Network) coverage (but only e.g. WLAN or Wireless LAN coverage as in a FMC scenario). Another means for the UE to indicate its location might be SSID (Service Set ID), but that would lead to a lot of administration for the operator. Also, SSIDs might be set by the owner of the residential network—and therefore not known to the operator.
The above-described issues are of course not limited to finding an ePDG in the specific context described above with reference to FIG. 1, but apply to any situation in which a terminal connects to its registered domain (or home domain) via an access domain and possibly an intermediate domain between the access domain and the registered domain, and where the terminal is attempting to find a gateway node (or indeed any other type of node) that is most appropriate or desirable (e.g. from a geographical and/or network efficiency point of view)—whether that gateway node be located in an intermediate domain or in the registered domain.
FIG. 2 is a schematic illustration of this wider context, and it can readily be seen that it is entirely equivalent to that of FIG. 1. The HPLMN 8 can be considered to be the “registered domain” for the UE 2, i.e. the domain at which the UE 2 is registered (for example the domain in which the user's profile is maintained and/or which is responsible for charging for services consumed by the user). The ANs 4-1 and 4-2 can be considered to be “access domains”, and the UE 2 can be referred to as a “terminal”. The VPLMNs 6-1 to 6-3 can be considered to be “intermediate domains”.
The technical problem as appreciated by the present applicant can therefore be summarized as one of identifying an appropriate gateway node for a terminal which connects to its registered domain (e.g. home domain) via an access domain and, in a predetermined scenario (e.g. a roaming scenario), an intermediate domain (e.g. a visited domain), particularly where the terminal does not have knowledge of its own location and cannot therefore pass this information on for assistance in selecting an appropriate gateway node. It is desirable to find a solution to this technical problem.